Cloud DNSの転送ゾーンを試してみた

概要

Cloud DNSでゾーンを作成する時には一般公開のゾーン以外にGoogle Cloud内部でのみ名前解決できるプライベートゾーンも作成することができます。
プライベートゾーンでは下記のオプションを選択することができます。

今回の記事では、実際にクエリを別のサーバに転送する機能(以下：転送ゾーン)のオプションを試してみました。
実際のユースケースとしてはプロジェクト間(DNSピアリングを用いたり)やVPN経由でのAWSへの転送やオンプレのDNSサーバへの転送などが考えられる機能です。

本記事では、オンプレやAWSへの転送ではなく2つのVPCとCloud DNSを用いて転送ゾーンの検証を行います。
Cloud DNSに転送ゾーンの設定を行い、名前解決テストインスタンスから名前解決(正引き)をして、別途検証用に構築したDNSサーバインスタンスのレコード値(TXTレコード)を取得することができるかどうかを試してみます。
イメージとしては以下となります。

それではやっていきましょう。

やってみる

今回作成するリソースは以下となります。

VPCの準備

1つのVPCとその中に2つのサブネットを作成します。

サブネットのip範囲は上記以外でも問題ないです。限定公開の Google アクセスやフローログはオフでよいです。
また、どちらのVPCのインスタンスもSSHで接続するのでFWのルールでSSHを許可します。

そしてSSH以外にCloud DNSからの転送用に35.199.192.0/19に対してTCPとUDPのポート53を内向き(ingress)で許可する必要があります。
このルールを設定しないとCloud DNSからゾーン転送することができませんので注意してください。

35.199.192.0/19 に対するファイアウォール構成
タイプ 1 の転送先の場合、TCP と UDP のポート 53 トラフィック用に上り（内向き）許可のファイアウォール ルールを作成し、承認済みの各 VPC ネットワーク内の転送先に適用します。タイプ 2 の転送先では、オンプレミス ネットワークのファイアウォールや同様の機器を構成して、TCP と UDP のポート 53 を許可します。

※引用：https://cloud.google.com/dns/docs/zones/forwarding-zones?hl=ja#private_targets

DNSサーバ用GCEインスタンスの構築

インスタンスは以下で作成しました。代表的な設定だけ取り上げます。

インスタンス作成後SSHで接続します。
DNSサーバにはBIND9を用いるのでBIND9および関連ツールをインストールします。

sudo apt update
sudo apt install bind9 bind9utils

1. GCEインスタンスにSSHで接続

まず、GCEインスタンスにSSHで接続します。作成したインスタンスを選択し、SSHボタンをクリックして接続します。

2. BINDのインストール

次に、BIND（BIND9）をインストールします。Debianベースのディストリビューションの場合、以下のコマンドを使用します。

sudo apt update
sudo apt install bind9 bind9utils

3. ゾーンファイルの設定

BINDの設定ファイルを編集して、ゾーン情報を追加します。

3.1. named.conf.local の編集

named.conf.local ファイルにゾーン情報を追加します。

sudo vi /etc/bind/named.conf.local

以下の内容を追加します（例としてtest.nemotonemoto.internalという架空のものを使用）：

zone "test.nemotonemoto.internal" {
    type master;
    file "/etc/bind/zones/db.test.nemotonemoto.internal";
};

3.2. ゾーンファイルの作成

ゾーンファイルを作成します。ゾーンファイルは通常 /etc/bind/zones/ ディレクトリに配置します。このディレクトリが存在しない場合は作成します。

sudo mkdir -p /etc/bind/zones
sudo vi /etc/bind/zones/db.test.nemotonemoto.internal

以下の内容をゾーンファイルに追加します：

$TTL    604800
@       IN      SOA     ns1.test.nemotonemoto.internal. admin.test.nemotonemoto.internal. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns1.example.com.
ns1     IN      A       192.0.2.1
@       IN      A       192.0.2.1
@       IN      TXT     "This is my private dns zone!"

上記の例では、@ は example.com ドメインを指し、ns1.test.nemotonemoto.internal のIPアドレスを 192.0.2.1 としています。また、TXTレコードとして検証用の値"This is my private dns zone!"を設定しています。

4. BINDの設定ファイルのチェック

設定ファイルにエラーがないか確認します。

sudo named-checkconf
sudo named-checkzone example.com /etc/bind/zones/db.test.nemotonemoto.internal

エラーがないことを確認します。

5. BINDの再起動

設定を反映させるためにBINDを再起動します。

sudo systemctl restart bind9

6. DNSの動作確認

digコマンドをインストールします。

sudo apt install dnsutils

digをループバックアドレスに対して実行して、設定したゾーン情報とTXTレコードが正しく応答するか確認します。

dig @127.0.0.1 test.nemotonemoto.internal TXT

ANSWER SECTIONが以下の通りであれば構築は成功しています。

;; ANSWER SECTION:
test.nemotonemoto.internal. 604800 IN   TXT     "This is my private dns zone!"

これで、GCEインスタンスにBINDをインストールし、ゾーン情報を設定してTXTレコードを追加する手順は完了です。
(とても荒削りなのであくまで検証用と考えてください)

Cloud DNSを設定する

転送ゾーンを作成していきます。
以下の設定値で作成します。

ネットワークをtest-dns-vpcと設定する点が重要です。ここで設定したネットワーク内でのみCloud DNSに設定したドメイン名を名前解決できます。

名前解決テスト用インスタンスからテストしてみる

test-instance-subサブネットにインスタンスを構築します。
digを使ったテストをするだけなので最低限のスペックで作成します。

作成できたらSSHで接続し、digコマンドをインストールします。

sudo apt install dnsutils

インストールできたらdigしてみます。

dig test.nemotonemoto.internal TXT

ANSWER SECTIONに以下の通り先ほど設定したTXTレコードが表示されていることが確認できます。

;; ANSWER SECTION:
test.nemotonemoto.internal. 604800 IN   TXT     "This is my private dns zone!"

本当にCloud DNSに作成した転送ゾーンを参照しているのか不安になったのでCloud DNSの転送ゾーンを削除してdigしてみましたが以下の通りstatus: NXDOMAIN=存在しないドメインという返答に変わっていることが確認できました(クエリできた場合はキャッシュが残っているのでインスタンスを再起動してみてください)。

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60825
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

上記の結果よりCloud DNSの転送ゾーンでDNS転送を行う(以下のイメージ図)ことが可能と確認することができました！

※不要な課金を防ぐため検証完了後インスタンスやゾーンの削除を忘れないでください。

まとめ

Cloud DNSの転送ゾーン機能を試してみました。
初めに触れた通り実際のユースケースとしてはプロジェクト間(DNSピアリングを用いたり)やVPN経由でのAWSへの転送やオンプレのDNSサーバへの転送などが考えられる機能です。あくまで今回は機能検証としてVPC内のDNSサーバに転送をしてみました。オンプレへ転送する場合はルーティング経路やルートのアドバタイズなど考慮することが他にもたくさんあると考えます。
オンプレへの転送をする機会はなかなかないので記事にするのは難しいですが、AWSへの転送やプロジェクト間の転送は手軽に試せるので今度また試してみたいと思います。

それではまた。ナマステー

参考

https://cloud.google.com/dns/docs/zones/forwarding-zones?hl=ja